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Abstract 

IBM's adoption of operating system personalities 
was one of the most publicized issues in operating sys- 
tems design. The basic premise of Workplace OS work 
was: 1) IBM would adopt and improve the CMU Mach 
3.0 microkernel for use on PDAs, the desktop , and 
massively parallel machines, and 2) that several oper- 
ating system personalities would execute on the micro- 
kernel platform concurrently. This architecture would 
provide users the best worlds as they switch betweeii 
applications written for different operating systems. 
IBM would also benefit from significant cost savings 
by having one common platform for all product lines. 

IBM’s plans for use of the microkernel and 
multiple-personalities, as a unifying mechanism for a 
widely diverse set of hardware products, have failed. 
Here we examine why IBM’s microkernel and multi- 
personality system was not successful from a techni- 
cal and business standpoint. We also discuss Power 
Personal systems, which were introduced during these 
radical software changes, and then later abandoned. 

1 Introduction 

We learn great lessons from engineering failures. 
Petroski[4] discusses some of the largest physical fail- 
ures such as the 1979 DC-10 crash in Chicago, when 
an improperly-maintained engine fell off during take- 
off, the Kansas City Hyatt Regency walkway collapse 
in 1981, the Tacoma Narrows Bridge failure that was 
captured on newsreel, and the well-known Challenger 
disaster. Petroski argues two points concerning these 
disasters. First, engineering is a human activity, prone 
to error and failure. Second, progress in engineering, 
like all human endeavors, comes by taking risks - that 
is how all engineering failures occur. 

IBM is a company with a history of taking engi- 
neering risks while also having its share of failures. 
Brooks [2] discusses several IBM failures in his book 
which focuses on software engineering and project 
management. However, less documented IBM fail- 
ures include the MicroChannel Architecture (MCA) 



and the PS/2, the token ring, Transparent Comput- 
ing Facility (AIX/TCF), and failure to achieve accep- 
tance of SAA and SNA architectures. More recently 
IBM proposed Workplace Operating Systems(OS), the 
portable successor of OS/2 based on the IBM micro- 
kernel that supports multiple personalities. IBM en- 
visioned Workplace OS would provide significant cost 
savings by having one common software platform for 
all product lines. In this paper, we outline the Work- 
place OS project and analyze why personalities failed 
to generalize. 

2 System Structure 

Figure 1(a) and (b)[3] shows the structures of the 
planned and the delivered microkernel for Workplace 
OS. The planned microkernel had multiple personali- 
ties. The dominant personality shown in Figure 1 was 
to be the primary personality presented to the user. 
The alternate personalities provide additional operat- 
ing system services to the user concurrently. Alternate 
personalities permit execution of different OS applica- 
tions from those provided by the dominant personality. 
Figure 1(a) also depicts personality neutral services 
(PNS’s) that provide shared services for the multi- 
ple personalities that run in user-space. Networking, 
file systems, scheduling, paging and security services 
are PNSs. PNSs reduce the size and complexity of 
each personality, and maximize the amount of shared 
application code. For example, IBM argued that in 
some systems such as Windows-NT, extending the op- 
erating system scheduler to support real time schedul- 
ing would be difficult. In Workplace OS, a real-time 
scheduler could be easily substituted as a PNS compo- 
nent in user space. Figure 1(b) shows the microkernel 
that was eventually delivered; multiple personalities 
were not implemented. 

In contrast to Workplace OS, Microsoft's Windows- 
NT supports five personalities: DOS, Windows, 32-bit 
Windows, OS/2 version 1.x, and a PO SIX-compliant 
UNIX-like personality [1]. However, the goals for per- 
sonalities in NT were substantially different from 
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Figure 1: IBM microkernel: planned and delivered structure 



Workplace goals. NT made no claims to unify a di- 
verse set of products with a common software plat- 
form. 

In conjunction with microkernel development, IBM 
planned to offer workstations based on the Motorola 
PowerPC which was touted as a more economical 
RISC machine that would execute personalities com- 
patible with the Intel processor. A Power Personal 
Systems Division was established with development 
facilities in Austin, Texas, Boca Raton, Florida and 
Yamato, Japan. The Division defined the PowerPC 
systems standard and planned to sell systems that 
ran all personalities. The PReP (PowerPC Refer- 
ence Platform) specification was created to specify the 
structure of the components for PowerPC machines[6]. 
In addition, IBM planned to push for acceptance of 
the microkernel as a new standard through the OSF 
Research Institute where many of the microkernel en- 
hancement ideas originated. 

3 Personalities 

Personalities provide binary code compatibility for 
applications and therefore supply two components: 
the application program interface (or API) and the ap- 
plication binary interface (or ABI). The API provides 
the set of functions that the personality exports and 
thus the API contracts what functionality the person- 
ality implements. The ABI dictates the format of the 
binaries that the personality executes. A UNIX per- 



sonality need only support the POSIX API for it to 
be called a UNIX personality. However, an AIX per- 
sonality must execute native AIX binaries in addition 
to supporting the AIX API. 

There were three key business reasons why person- 
ality support was important to IBM. First, DOS, Win- 
dows, and Mac programs are currently the dominant 
software on store shelves; obtaining shelf space for a 
new incompatible software variant would be difficult, 
even for IBM. Second, users have come to expect and 
are not about to discard significant software invest- 
ments made on application programs, no matter how 
impressive the new operating system promises to be. 
Third, compatibility for the PowerPC was a key issue 
in order for users to adopt it. Success of the Power 
Personal System Division required software products 
provide ABI compatibility. Personalities were touted 
as a means to protect the user’s software investment 
in addition to providing a necessary and familiar API. 

4 Difficulties 

The task of creating personalities for the microker- 
nel was more challenging than originally envisioned, 
even for architectures with compatible instruction 
sets. The problems arose from two areas: structur- 
ing and binary compatibility. Both issues were impor- 
tant to Workplace’s success, yet after the conceptual 
design was finished and the actual implementation be- 
gan, numerous unforeseen problems arose. 









Operating system structuring is a fundamental de- 
sign issue and one of the most important reasons for 
adopting a microkernel. The IBM microkernel archi- 
tecture specifies the need for clean separation of shared 
personality services to avoid duplication of the ser- 
vices in each personality. However, clean separation 
of shared services required substantial changes to per- 
sonalities that wasn’t well considered early in the de- 
sign. For example, when IBM tried to integrate OS/2 
with Windows, problems arose in that both Windows 
and OS/2 supported their own memory manager. Un- 
able to modify windows code to use OS/2s memory 
management (although IBM licensed the source code 
from MS), IBM resorted to using the Windows mem- 
ory manager within the OS/2 memory manager. The 
result was that Windows manipulations of memory 
could spill over into the OS/2 swap file. Similarly, 
display drivers needed to be substantially reworked to 
manage screen space between the two personalities. 

A second major problem was the need to support 
incompatible executable code. The Microsoft solution 
in Windows-NT uses virtual machines that permits 
Intel code to be executed on a virtual Intel x86-based 
machine. IBM established a goal for all Power Per- 
sonal systems, no matter what the operating system 
port, to run DOS/Windows binaries. This support re- 
quired IBM provide two components: an API remap- 
per and a binary translator. Specifically, at the API 
level, IBM supports WABI for API remapping, as 
well as developing Windows capability in OS/2. At 
the emulation level, IBM has developed an instruc- 
tion set translator that compiles blocks of 80x86 code 
into blocks of PowerPC code on-the-fly and performs 
optimizations in the background. OS/2 for PowerPC 
had a split personality: an OS/2 personality and this 
DOS/Windows instruction set translator. 

A third major problem was support for AIX, IBM’s 
UNIX product. Early in the project, IBM announced 
plans to port the monolithic AIX to the PowerPC. 
The AIX port from the RS6000 Power architecture 
to PowerPC was easy since the PowerPC executes all 
Power instructions. However, an important goal of 
Workplace was to unify IBM’s diverse product line. 
Therefore, AIX must operate on Workplace and in- 
dustry observers regarded existence of an AIX per- 
sonality essential for Workplace to be successful. On 
the other hand, support for an AIX personality on 
Workplace was a challenging problem because both 
OS/2 and the microkernel were Little Endian but AIX 
was Big Endian. An IBM press release indicated that 
IBM planned to address this problem by assigning an 
IBM Fellow to “crack the problem” along with a small 



team 1 of IBM’s best research minds. However, sup- 
porting both OS/2 and AIX personalities simultane- 
ously would require software emulation code to switch 
byte ordering 011 -the-fly which would substantially de- 
grade AIX performance. 

5 Project History 

In January 1991 the project was conceived. The 
first presentation of IBM’s new operating systems 
strategy was given to internal management with a 
chart referred to as the Grand Unification Theory of 
Operating Systems (or GUTS, for short). GUTS out- 
lined how one microkernel would unify several operat- 
ing systems with common “subsystems”. At the end 
of 1991, a small team from Boca Raton, Florida and 
Austin, Texas had been formed to begin work on a 
version of the Mach Microkernel to support OS/2, the 
lead personality. In the summer of 1992, the prototype 
was underway and there was good progress. IBM suc- 
cessfully demo ed OS/2, DOS, DOS/Windows, and 
Unix running on the Mach microkernel at the Fall 
Comdex in 1992. 

Soon after IBM announced plans to develop OS/2, 
DOS, and Unix as microkernel personalities for both 
PowerPC and Intel architectures [5]. At Comdex in 
1993 IBM Chairman Louis Gerstner announced that 
the microkernel would not replace AIX. Instead, Ger- 
stner told AIX customers that they would be able to 
migrate to Workplace OS, later. Subsequently, intense 
work on Workplace followed. IBM divided five major 
personality projects across separate divisions. Each 
division was required to support their own OS person- 
ality on the microkernel. In addition, a microkernel 
business unit was established to market the microker- 
nel and create University relationships. 

In May 1994 the division director of RISC Systems 
software announced plans to study an AIX personal- 
ity for Workplace. A small internal research team of 
less than ten members was assembled and led by an 
IBM Research Fellow. The announcement was accom- 
panied by information that a significant problem with 
development of the AIX personality was that of byte- 
ordering. IBM also reminded customers that mono- 
lithic AIX runs perfectly well on the PowerPC and 
that IBM needed time to address this difficult endian 
problem. 

Seven months later in January 1995, IBM an- 
nounced the AIX personality effort would be halted 
and an AIX personality for Workplace would not be 
built. Instead in February, IBM announced that it 
would offer a non- AIX personality for Workplace. The 
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new UNIX personality was intended for users that 
might otherwise find themselves rebooting between 
microkernel OS/2 and AIX. 

In October 1995 IBM finally announced the gen- 
eral availability of Version 1 of the microkernel for the 
PowerPC. In the first year of release, IBM had sev- 
eral commercial vendors and Universities that adopted 
the microkernel including Digital Equipment Corpo- 
ration, LG Electronics (Goldstar), Komatsu, Trusted 
Information Systems, and Bell-Northern Research. In 
addition, Universities such as Carnegie-Mellon Univer- 
sity, Notre Dame, Oregon Graduate Institute, Univer- 
sity of California at Irvine and Riverside, University 
of Texas, Arlington, Helsinki University of Technology, 
Tokyo University, and Cornell University were using 
IBM’s microkernel for their research. 

Later in October, media reports began to circulate 
that the PowerPC 620, which was the basis for the new 
improved desktop PowerPCs, was bug-ridden. Shortly 
after this news, IBM cancelled the Workplace project 
and folded the Power Personal Division. The latest 
and last release of the stillborn microkernel, version 
2.0, was distributed to microkernel adopters early the 
following year. The final release supported the Mo- 
torola PowerPC, Intel x86, and the ARM (Advanced 
RISC Machine ) embedded processor. 

Table 1 summarizes assumptions versus out- 
comes associated with IBM microkernel personalities. 
Sources indicate that $2 billion dollars was spent on 
the Workplace project making it one of the most ex- 
pensive operating system failures in history. Approx- 
imately one year after cancellation of Workplace OS, 
the IBM Boca Raton, Florida facility was closed. 

6 Project Management 

It is difficult to assess the quality of project man- 
agement from an outside perspective. However, the 
combination of effective project management and high 
quality software engineering is essential for techni- 
cal innovations to be successfully committed to prod- 
ucts and is essential to the success of large soft- 
ware projects. Therefore many software companies 
in Japan and Europe have aspired to meet the inter- 
national standard ISO 9000-3 which is the software- 
specific version of ISO 9001. The ISO standard pro- 
scribes specific management activities that guarantee 
quality during the software production cycle. The ra- 
tionale for ISO standards argues that even great in- 
ventions will not benefit companies that have chaotic 
processes. 

Despite the compelling need, we speculate 2 that 

2 IBM did not officially comment or provide assistance con- 
cerning this part of the evaluation 



software engineering and ISO standards may have 
taken a back seat in Workplace design which fo- 
cused on significant new innovations to support cross- 
platform adapatability. However, effective project 
management was essential to Workplace since there 
were over 400 microkernel programmers [6] and 1500 
OS/2 programmers [7] geographically distributed in 
different divisions. In contrast, Microsoft employed 10 
people on Windows-NT and later another 40 or 50[1] . 

7 Lessons 

To summarize, we offer the following lessons from 
analyzing Workplace: 

1. It’s easier to create a plan than a working oper- 
ating system with multiple personalities. Overly 
ambitious (GUTSy) goals lead to failure. 

2. IBM underestimated the difficulty in creating per- 
sonalities. Each personality required extensive re- 
structuring to support shared PNSs. These divi- 
sions were not always easy to delineate or imple- 
ment as common subsystems. PNSs require that 
personality designers communicate effectively to 
reach common agreement on goals and imple- 
mentation strategies for shared services. 3 Also, 
co-existence of ABI-compatible personalities with 
different “endianness” presented insurmountable 
problems. 

3. IBM considered personalities late when com- 
pared to the microkernel where considerable ef- 
fort on functionality, efficiency, and portability 
was placed early in the design. In contrast, in 
Windows-NT, personalities were considered early 
in the design and there was no emphasis on gen- 
eralizing the NT microkernel for all products. 

4. It was poor judgement for IBM to require all di- 
visions to support the microkernel until more re- 
search had been conducted on its applicability 
across the diverse product lines, the applicabil- 
ity across existing software products, and to have 
one prototype with all essential personalities. In 
addition, IBM should have marketed personality- 
based PowerPCs after having the essential per- 
sonalities prototyped. Associating the success of 
Power Personals with the success of personality 
development was unwise. 



3 Brooks [2] p.16-19 has a good discussion of the problems 
that arise on large software projects when there is a need to 
communicate between parties. 




Personality Assumptions 


Personality Outcomes 


UNIX, OS/2, OS/400, Windows would run side- 
by-side on the microkernel as personalities. 


OS/2 and Windows-NT ported to PowerPC with- 
out IBM microkernel. 


PowerPC price/performance would attract cus- 
tomers along with a multi-personality operating 
environment. 


Delays in introduction of software and hard- 
ware reduced performance advantage of PowerPC. 
Without personalities, PowerPC incompatibilities 
outweigh benefits. 


IBM invites Apple to adopt the microkernel for 
Mac OS. 


Apple refuses microkernel adoption and states 
that the microkernel has excessive resource re- 
quirements. About one month later IBM an- 
nounces a marketing study indicating there is no 
customer demand for Mac OS on the PowerPC. 


IBM announces a study of a Workplace AIX per- 
sonality. IBM would address this problem by as- 
signing an IBM Fellow to “crack the problem” 
along with IBM’s best research minds. 


AIX personality abandoned in January 1995 and 
IBM denies any original plans to support an AIX 
personality. IBM cited success of monolithic AIX 
on PowerPC and continued work on OS/2. Pri- 
vately, some IBM executives admitted Workplace 
was dead. 


In February 1995 IBM announces non-AIX per- 
sonality for the microkernel described by IBM as 
a variant of AIX with a non-AIX API. 


A new version of UNIX is not welcomed. The 
media expresses concerns whether Workplace will 
be successful. 


In March 1995 IBM clings to late summer release 
date for OS/2. 


In June 1995 IBM ships PowerPCs with mono- 
lithic AIX and Windows-NT. In July 1995 IBM 
quietly announces it will have Mac OS on Power- 
PCs next year. 


In October 1995 reports circulate that the Pow- 
erPC 620 is bug-ridden. 


IBM announces end of Power Personal Division 
and the end of the microkernel strategy. 



Table 1: Assumptions and Outcomes in Personality Development 



5. Both IBM and Microsoft used different ap- 
proaches to preserve the user’s software invest- 
ment. Workplace announces an architecture- 
centric view to customers. IBM marketed a solu- 
tion looking for adopters that was not a working 
solution. Microsoft, in contrast, has a user-centric, 
view hiding details of the underlying approach 
and instead focusing on end-users. Microsoft ap- 
peals to the customers concern in NT with what 
applications run on the machine, not what is “un- 
der the covers” and how it works. 



6. University research and prototypes could have 
saved IBM a substantial amount of money and 
exposed difficulties in generalizing concepts. In- 
stead, funding was directed primarily to OSF and 
away from Universities who were viewed as micro- 
kernel adopters and personality developers rather 
than designers, implemented, participants and 



evaluators of the overall Workplace OS 4 . 

7. Sound software engineering practices and ISO 
techniques may have helped. Coordinated project 
management was a key issue for success of the 
project. 

The Workplace project organizers seemed to lack 
good technical judgement. In [4]p.l21, Petroski states: 

The first and most indispensible design 
tool is judginent. It is engineering and design 
judgment that not only gets projects started 
in the right direction, but also keeps a critical 
eye on their progress and execution. Engi- 
neering judgment, by whatever name it may 
be called, is what from the very beginning of 
a conceptual design indentifies the key ele- 

4 Privately. IBM continues to express doubts concerning the 
value of conducting University funded research favoring its own 
internal research labs. 





merits to go to make up an analytical ex- 
perimental model for exploration and devel- 
opment. It is judgement that separates the 
significant from the insignificant details, and 
it is judgment that catches analysis going 
astray.... Judgement, in short, is what avoids 
mistakes, what catches errors, what detects 
flaws, and what anticipates and obviates fail- 
ures. The single most important source of 
judgement lies in learning from one’s mis- 
takes and those of others. 

We often learn more from designs that have failed than 
designs that have been successful. Operating systems 
conferences and systems-oriented journals would best 
serve designers by discussing design failures more of- 
ten. In short, IBM’s failure in Workplace is a joint 
academic failure; academics have placed overly heavy 
emphasis on reporting sucesses in operating system 
work rather than failure where we learn the most. 

The blame for Workplace cannot be entirely at- 
tributed to not having sufficient academic forums for 
discussing failures. It was IBM’s responsibility to 
learn from lessons of the past; the IBM/360 project 
and the failures reported by Brooks [2] seem to have 
repeated themselves in Workplace. How could IBM’s 
previous failures seemingly repeat themselves in this 
new project? Petroski’s analysis[4]p.l66 is revealing: 

The relationship between success and fail- 
ure in design constitutes one of the funda- 
mental paradoxes of engineering. The ac- 
cumulation of successful experience tends to 
embolden designers to attempt ever more 
daring and ambitious projects, which seem 
almost invariably to culminate in colossal 
failure that takes everyone by surprise. In the 
wake of failure, on the other hand, there is 
generally a renewed conservatism that leads 
to new and untried design concepts that 
prove ironically to be eminently successful 
precisely because the design process proceeds 
cautiously from fundamentals and takes lit- 
tle for granted. As the new form evolves 
and matures, however, the cautions atten- 
dant upon its introduction tends to be forgot- 
ten, and a new period of optimism and hubris 
ensues. 

Engineering is an imprecise science because it relies on 
judgement. Human error is a major cause of design 
errors throughout history. Leaning from past errors, 
with case histories such as this analysis of Workplace 
OS, can greatly assist in preventing future errors. 



8 Conclusion 

IBM’s failure is a story of overly grandiose GUTSy 
ambitions, ineffective project management, and fail- 
ure of personalities to generalize beyond their tested 
previous scope. In this paper, we described the Work- 
place OS project and how it proceeded from grandiose 
vision to grandiose failure. We presented lessons we 
learned from examining and analyzing Workplace. We 
observed that good judgement is essential to successful 
designs and that failure-based paradigms sharpen our 
judgement. We offered insight concerning how past 
engineering failures operate in a cycle of success and 
failure and it is from failures we can learn the most. 
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